Almathera Ten Pack 2: CDPD 1/Almathera Ten on Ten - Disc 2: CDPD 1.iso/pd/476-500/500/wiconify/update.history

Text File | 1995-03-14 | 28KB | 495 lines

---------------- v3.8 ------------------

In the past, System Request windows were not handled well by wIconify.  This
is due to the fact the Intuition does not use its own vector table, so when
wIconify traps the OpenWindow() routine, it sees all the new windows except
the ones created by Intuition iteself.  These include windows created by
AutoRequest() and by BuildSysRequest(), which are part of the Intuition
Library.  Although these windows could be iconified, wIconify would not
transfer them to other screens, despite the settings of the OPEN_ON menu.
Moreover, if an iconified System Request were closed (due to a disk insert,
for example), the window would close, but the icon would not be removed
from the screen.  Worse yet, an attempt to open the icon could result in a
system crash!

These problems have all been resolved with this release of wIconify.  The
wIconify handler now includes traps for the AutoRequest(), BuildSysRequest()
and FreeSysRequest() routines.  BuildSysRequest() now checks to see if the
new window should be opened on a different screen:  if a screen was
specified, the system request appears on that screen; otherwise, if the task
that calls BuildSysRequest() is a Process, and the process has its error
window pointer set (by wSetSysRequest, for example), then the system requester
will appear on the screen containing that window; otherwise, the window will
be opened on the screen determined by the OPEN_ON menu setting.

In addition, the new BuildSysRequest() will bring the screen where the
requester was opened to the front if it is not the active screen, and will
change the window title from "System Request" (or nothing at all) to the
name of the process that is making the system request.  This should help you
to identify the program that has caused the system request.

Window opened by BuildSysRequest() are new fully supported by wIconify:
they can be iconified and manipulated as usual, their icons will be removed
when they close, and their presence on a "foreign" screen will prevent that
screen from closing before the system request is completed.

The AutoRequest() routine presents more of a challange, since it does not
return control until after the system request window has been completed.
Thus wIconify never gets the chance to manipulate the window it creates,
either to move it to another screen, or to maintain the internal data
required for an icon.  For this reason, the AutoRequest() routine has been
completely replaced by an equivalent routine.  This routine calls
BuildSysRequest(), and then waits for the user to complete the request.
The action of the AutoRequest() routine is well-documented in the Intuition
manual, so this replacement should be indistinguishable from the original
under normal circumstances.  Please contact the author of wIconify if you
find any discrepencies.

---------------- v3.7 ------------------

There are a number of new features to v3.7, most notably, the ability to
iconify screens as well as windows.  To iconify a screen, simply left-right
click in the wIconify backdrop window (ie, attempt to iconify the backdrop
window).  The screen will be replaced by an icon on the Workbench screen.
Screen icons differ from window icons so it is easy to distinguish among them.
There is also a new ICONIFY item in the SCREEN menu.  Selecting this menu
item is equivalent to left-right clicking the backdrop window.

There are now SCREEN_IMAGE, SCREEN_SELECT, and SCREEN_MASK commands in the
wIconify initialization file that allow you to customize the imagery for
screen icons.  Screen icons do not support the NOCLOSE or CHANGEREFRESH
flags, however, for obvious reasons.

wIconSetter also includes the ability to specify screen icons:  if an icon
follows a SCREEN command directly (with no intervening WINDOW command), that
icon is treated as the screen's icon.  Screen icons support the AUTOICONIFY
flag.  Note, however, that wIconify screens are not able to be specified by
wIconSetter, for technical reasons (see the wIconSetter documenation for
details).

Finally, there is a new wIconifyScreen command that allows you to request
that a screen be iconified from the CLI command line (although the command
"wIconifyWindow wIconify [screenname]" also would do the job).

Another new menu item in wIconify is LOCK in the ICON menu.  If you lock an
icon, this means that wIconify will not allow it to be moved for any reason
(except a wMoveIcon() call from the programmer's interface).  This makes it
possible for you to specify icons that will not be altered by tbe ORGANIZE or
CLEANUP menus (programs that use the programer's interface, eg, wIconClock,
can specify this, but now the wIconify user can as well).

The timing of activating windows as their icons are opened has been updated.
In the past, the newly-opened window would be activated as soon as it was
uniconified (that is, as soon as the second mouse-down event occured).  The
mouse-up event then would be sent by Intuition to the newly-activated
window.  This "unmatched" mouse-up event may have been causing problems for
some programs.  In order to avoid this, wIconify now waits to activate the
window until the mouse-up event occurs.  If another window becomes active in
the meantime, however, wIconify will not activate the uniconified window.

wIconify's handling of the left-right click also has been updated.  In the
past, wIconify did not remove the left-right click from the input event
list, since this might produce unmatched mouse-up and mouse-down events; all
events were passed on to Intuition unchanged.  This had the disadvantage,
for example, of flashing the menu bar when a window was iconified.  Now,
however, wIconify will remove both mouse-down and mouse-up events for the
left-right click (or whatever ICONIFY_KEY is specified in the initialization
file).  The same holds for the ACTIVATION_KEY events.  This should help
prevent unwanted side effects of iconifying windows and screens.

A number of internal updates to the programmer's interface have required
that all the utility programs be relinked.  Older versions will report a
version mismatch when used with the v3.7, and the new versions will not work
with the older wIconify versions (this sort of thing will not occur once the
production version of wIconify is released, but it was convenient to make
some internal message-class and flag numbering changes at this time).

Some minor improvements were made to the code that deals with "worst case"
problems like screens closing as icons are opening, etc.  In particular, the
wiconify-ending code was improved.  wIconify is an extremely complex and inter-
related peice of software, and these changes could have introduced subtle
bugs in some operations.  Please give wIconify a complete shake-down, and
report any bugs you find.  This should be the last beta version before release,
provided nothing serious crops up in this final testing.

---------------- v3.6 ------------------

In the past, when the Workbench was loaded while wIconify was running, the
usual workbench backdrop window was modified to include a boundary, and to
reduce its size to fit more comfortably on the screen, but it remained an
unmovable backdrop window.  With this version of wIconify, the Workbench
window is modified further to be a non-backdrop window that includes sizing,
drag and depth gadgets as well.  This makes it much easier to handle in the
wIconify environment.

Be aware, however, that the Workbench does not provide sliders for this
window, so any icons that are moved off the edge of the window (by making
the window smaller, for example), will not be accessable while they are not
being displayed.  The window size will have to be enlarged in order to make
them available again.

---------------- v3.5 ------------------

Added ability to use quotation marks to delimit strings in the wIconify.init
file (for screen names, CLI commands, etc).  The single quote character is
used as the string delimiter (since CLI commands may need the double quote
as part of the command).  To include a single quote within the quoted
string, use two quotes in a row; eg., 'It''s quoted'.  You do not NEED to
use quotes, but you may use them if you want to include leading or trailing
spaces, for example, which normally are removed from the string.

Added COMMAND_STACK command to the init file.  This specifies the size of the
stack for the CreateProc() command that is used to execute the CLICommand
when the NEWCLI menu is selected.  Note that this does NOT set the stack
size of the shell created by a NEWSHELL command, but rather sets the stack
of the process that performs the NEWSHELL command.  You still should include
a STACK command in the script executed by the NEWSHELL command.  The
COMMAND_STACK command is mainly for if you specify a command other than
NEWSHELL as the CLICommand for NEWCLI.

Added HANDLER_PRIORITY command to the init file.  This specifies the
priority (in the Input Device handler chain) of the input handler that
wIconify uses to check for the iconify button (or key) sequence.  The priority
in this chain determines who gets to look at input events first.  Since
there are many different programs that use this chain, you may need to
be able to set the order yourself.  HANDLER_PRIORITY may help. The default is
51 which puts it just in front of Intuition.

In the past, wIconify would update the NEWSCREEN submenu values to match
the current screen whenever a wIconify window was activated.  Now, the
submenu is updated only when the wIconify window on a different screen is
activated.  This should make it easier to open screens of different resolutions
from the current screen.  The automatic updates were causing excessive updates
when SunMouse-type utilities were in effect.

Repositioned the menus so that they fit better on a low-resolution screen.
Also, wIconify now will not display menus on screens that are not tall
enough to display the whole menu, since otherwise this could crash the
system.  wIconify does not check for screens that are too thin, however.

Fixed subtle deadlock bug with the Workbench (wIconify would hang if the
WB window was iconified while a WB icon was being dragged).

Fixed a bug with the END command, where wIconify thought it had to wait for
additional replies from programs that use the wIconify programmer's interface.
Also, wIconify now replies all outstanding messages before it exits, rather
than leaving them in limbo.

Modified the handling of icons with MASKs.  The gadget associated with the
icon now uses the mask as a BOOTEXTEND mask; i.e., the gadget will only be
hit when you hit within the mask, and will only complement the part of the
image within the mask (you can use the mask to get the same type of effect
as the Workbench BACKFILL icons).  For icons that supply SELECT images, the
MASK is only used when the icon is selected (the unselected icon will have
no BOOLEXTEND mask).  As before, the MASK is also used as the BOB mask when
dragging the icon around the screen.


---------------- v3.4 ------------------

Internal and cosmetic changes only, in order to accomodate new functions of
wIconScreen.  wIconify now prints the version number when it is started.

wIconScreen now allows you to specify whether the newly created screen
will become the active screen, and whether to send the screen to the back
once it has been opened.

ScreeToFront and ScreenToBack now allow you to specify that the new front
screen should be activated once it is depth-arranged.

---------------- v3.3 ------------------

Version 3.3 finally separates the wIconify loader from the handler.
wIconify is the loader and wIconify-Handler is the handler.  Assign
WICONIFY: to be the directory where wIconify, wIconify-Handler and
wIconify.Init are stored.  (wIconify will also be found if it is in C:,
wIconify-Handler will be found if it is in L:, and wIconify.Init if it is
in S:).

You no longer need to RUN wIconify, since the wIconify command now loads
the handler and then exits.  To remove wIconify, either execute the wIconify
command again, or select the END menu item from the wIconify menu (this will
execute the wIconify command automatically, so the wIconify command must
be in the WICONIFY: directory, or in C:).

There are no other major features.  There have been some potential bug
fixes (notably the CLI reference that I discussed in a mail message).
There also is a new DEFAULT_FLAGS flag for the init file:  NOORGANIZE.
This flag specifies that the ORGANIZE command should not include the
marked icons.

The wIconClock program has been updated to include the ability to specify
the starting position of the clock icon.  Simply include the x,y coordinates
on the command line (no spaces between them).  For example:

    1>  wIconClock MILITARY 400,25

would open the clock at 400 pixels from the left and 25 down.

In addition, wIconClock now includes twice as many positions for the big hand.
This makes the clock look more "real".

Pretty much everything else is the same.

---------------- v3.2 ------------------

I have fixed everything except the New CLI stuff that we have been discussing.
As I have mentioned, I don't think there's anything I can do about that.

There are a number of new features since the last version I sent.  Most
of these are in the programmer's interface, however, so you won't notice
them in your daily use.  Some notable exceptions, however, are the following:

There is a new OPEN WINDOWS sub-menu in the SCREEN menu.  This sub-menu
allows you to specify where wIconify will open windows that are destined for
the WB screen, and whether to change the window's size to fit the specified
screen.  Windows can be opened on the ACTIVE SCREEN (the screen with the
active window), the CURRENT WB SCREEN (it's MAKE WB menu item will be
disabled), or on the REAL WB SCREEN (wIconify will not modify the window in
any way).  The windows can be resized automatically, or not, as you prefer.
If a window is too large for the screen where it is opening, and if
SIZE TO FIT is checked, and if the window accepts NEWSIZE events or has a
sizing gadget, then wIconify will attempt to resize the window to fit the
screen.  If the window also has a drag bar, the window may be repositioned
if that helps to fit the window to the screen.

Some menu items have been moved to accomodate the new menu, and some command
key equivalents have been changed.

Command key equivalents have been added to all menus except the CLOSE SCREEN
item and the END item (these seemed too apt to accidental selection).
Although the NEW SCREEN depth menu items do not show command equivalents,
they are available via right-amiga 1 through right-amiga 5.

There is a new utility program called wOpenOn to control the OPEN WINDOWS
sub-menu defaults for use within the startup-sequence.  See the separate
documentation for the program for more information.

There are new ScreenToBack and ScreenToFront programs that allow you to
depth arrange screens from a CLI.  See the separate documentation for more
information on these commands.

There is a new wSetSysRequest command that allows you to make system
requesters show up on the screen where a CLI is opened rather than on the
WB screen.  See the separate documentation for more information.

wIconify now looks for an initialization file called WICONIFY.INIT in the
current directory.  If it is not found, it looks in the S: directory.  The
initialization file allows you to customize many features of wIconify,
including:  the button or key sequence that iconifies a window; the button
or key sequence that activates the wIconify backdrop window; the qualifiers
needed to convert SMART_REFRESH to SIMPLE_REFRESH windows; the default icon
flags for iconified windows; the default color map for screens opened by
wIconify; the menu command key equivalents for the wIconify menus; the names
of screens that wIconify should not open backdrop windows on; the priority
at which wIconify should run (not yet implemented); the CLI command that
should be used for the NEW CLI menu item (a separate command can be
sepcified for HiRes and LoRes screens); the OPEN ON and SIZE TO FIT defaults;
and the imagery for the default icon.  These are explained in more detail
in the documentation for the initialization file (I haven't finished this
yet, but will send it as soon as it is done.  I will send a sample
initialization file for you to use as an example).

The only remaining task is to separate loader from handler.  The size of the
executable is quite large at the moment, but most of this will become the
loader (I hope), and the handler should be about 20K in the end, if all goes
well.


---------------- v3.1 ------------------

I have fixed all the bugs that you reported, and have added the new
features that we discussed in our recent EMAIL.

Major changes since the last version that you received:

wIcons now remember where they where last placed, and when a window is re-
iconified, it's icon will appear where it last was on the screen (this was
available with the programmer's interface, but was not the default; it was
simply a matter of changing the default in order to get this to work).

wIconify now traps the WindowToBack(), WindowToFront() and ActivateWindow()
Intuition routines to virtually guarantee that an iconified window will not
become the active window, and to make it almost impossible for a window to
fall behind the wIconify backdrop window accidentally.  Unfortunately, this
still does not fix the dropcloth problem.  It appears that dropcloth
is calling a lower level routine (LayerToBack() rather than WindoToBack()).
I could trap this one as well, but its usage is so rare by normal programs,
that I just don't think it's worth it for dropcloth, particularly since I
will be suggesting that people use dropcloth on the wIconify window rather
than the WB window.  The work around would be to be sure that the window
containing the dropcloth is iconified when you remove the dropcloth.  I will
probably have to provide a utility to recover "lost windows" that may escape
my attempts to make wIconify bullet-proof.

(Incidentally, wiconify can be used to make dropcloth active in ANY window
on the WB screen.  Whatever window was last iconified when you run dropcloth
will get the dropcloth image or pattern.  Personally, I find it rather
disturbing that dropcloth does not take more care in choosing the window to
modify.  It's not that hard to check for the real WB window.  It also makes
assumptions about the window's refresh flags when it removes itself:  it
always resets it to a SIMPLE_REFRESH BACKDROP window.  If its going to be
allowed to modify just any old window, it should at least retain the
original flags.)

wIconify now responds to the programmer's interface calls.  In particular,
I have provided the programs wIconScreen, wMakeWB, and wIconifyWindow that
use the programmer's interface to create new wIconify screens, select a
screen as the current WB screen, and iconify a specified window.  See their
separate help files for more information.

wIconify now has a hot-key that activates the wIconify backdrop window on
the active screen.  This makes it easy to get to the wIconify window's menus
even if there is a full-sized window in the way (that you don't want to
iconify for some reason - like it takes up too much memory).  The default
key is SHIFT-F1, but this will be configurable soon.

Many other minor adjustments have been made to make wIconify more robust,
and to allow greater flexibility within the programmer's interface (soon to
be documented).


The remaining tasks are:  finish testing all features of the programmer's
interface and write the example programs;  add the customization features;
separate the loader from the handler; and document the code.

Customization will include a separate program called wIconSetter that allows
you to specify alternate icon images (and other icon features) for windows
created by programs that do not know about the programmer's interface.
There will also be an icon editor included with this, and a program that
clips a selected region off any screen and writes an icon image from it.

---------------- v3.0 ------------------

This is a test version of wIconify, so not all the functions are
implemented.  In particular, it has not been broken into a separate loader
and handler, so you will have to RUN WICONIFY in order to use it.

Once installed, you can send a CTRL-C to the wIconify process or use the
END menu item in order to remove wIconify.

New Features:

wIconify now allows you to iconify windows on any screen.  To iconify a
window, simply click the right button while holding down the left button
(this is called a left-right click).  The window will be iconified and its
icon will appear on the screen where the window exists, in the colors and
resolution of that screen.

In order to allow icons on any screen, wIconify opens a backdrop window
every screen.  If the screen itself already has a backdrop window, you may
need to iconify it in order to get access to the wIconify backdrop window.
In order to allow this, wIconify now will iconify backdrop windows (it did
not do so before).

Since there is now an icon window on every screen, wIconify uses the menu
bar of these windows for its menus rather than inserting them into the
Workbench menu bar.

The wIconify menus now include screen manipulation functions in addition to
the icon manipulation functions.  These include SCREEN TO FRONT and SCREEN
TO BACK which allow you to flip through all the screen, even those that do
not allow access to their depth gadgets.  Also, there is a function that
allows you to make any screen into the Workbench screen; i.e., the screen
where windows that do not specify their own custom screens will open.
This makes it easy to open CLI windows or other programs on any custom
screen.  There is also a funtion to bring the current WB screen to the
front, and a menu item that opens a new CLI on the current screen (provided
you have the RUN and NEWSHELL commands in your C: directory).  Also,
there is a menu item that allows you to open a new screen to use as the WB
screen.  You can choose among the HIRES, INTERLACE, and HAM flags (in any
combination, provided yo uhave the memory for it), and can choose from 1
to 5 bitplanes (HAM screens always get 6 however).  There is no support
currently for DUALPF or EXTRA_HALFBRIGHT modes, but there are not a lot of
WB programs that use these :-)  Finally, there is a menu item to allow
you to close a WB screen that wIconify created (provided there are no windows
open on it).

wIconify keeps track of the windows that it opens on custom screens, and
will not allow these screens to close while there are still windows open on
it (the program will Wait() until all the windows are closed before it is
allowed to complete the CloseScreen call).  Thus it is safe to open windows
on custom screens that wIconify did not create.

wIconify still has the original CLEAN UP, ORGANIZE, and OPEN ALL menus, and
the VERSION item has been changed to ABOUT.  Since wIconify is no longer
using the Workbench menu bar, it also include OPEN and CLOSE menus.  All
menu items except END, CLOSE SCREEN, and NEW SCREEN have command key
equivalents.

The reviews of version 2.0 of AmigaDOS and the new Workbench indicate that
the Workbench will now use its own standard (non-backdrop) window, with
sliders and a sizing gadget.  For this reason, wIconify no longer attaches
itself to the workbench window, but rather opens its own backdrop window,
even on the Workbench screen.  This is fine for version 2.0 of the system
software, but makes it difficult to get to the wIconify window for current
workbench users (one can iconify the Workbench itself in order to get to the
wIconify window, but this seems needlessly cumbersome).  In order to
overcome this temporary problem, wIconify provides a simple-minded fix.  It
watches for the workbench window to open, and when it does, it reduces it
to a smaller size, adds a border, and places it at the right of the screen.
It still remains a backdrop window, however.  It should be an appropriate
size and shape for displaying the disk icons, while still giving room to
view the wIcoinfy icons in their own window.  (I would welcome suggestions
for a better solution).

There are two additional functions that have been requested most often by
users of the older version of wIcoinfy.  The first is to be able to iconify
Workbench disk and folder windows.  The old wIconify took special action to
prevent this, since the WB windows already had icons (the disks or drawers
themselves), but since these require disk access to open, people wanted to
be able to iconify them.  This feature has been added (or removed, depending
on how you look at it).

The second request is a little more complex.  The current effect of
iconifing a SMART_REFRESH window is essentially to copy all the data into an
off-screen area, just as would happen if the window were entirely covered by
other windows.  Thus iconifying a window usually causes MORE memory to be
used rahter than less (this is only true for SMART_REFRESH windows;
SIMPLE_REFRESH and SUPERBITMAP windows do not take more memory to iconify).
People have requested that wIconify treat a SMART_REFRESH window as a
SIMPLE_REFRESH window when it is iconified. in order to reduce the amount of
memory used.  While possible, this is a reasonably dangerous thing to do in
general.  First, if not synchronized properly, it can cause serious
confusion in the screen update process (updates can fail to occur or can
occur incorectly); it is very difficult to get the screen back to a correct
state once this has occured.  Second, and perhaps more important, all data
in the window will be lost while it is iconified, and since most
SMART_REFRESH windows do not process refresh events, the data will not be
restored when the icon is openned again.  Programs that do not provide a
method of redrawing their window's contents might not be able to recover
from this loss of screen data, and the windows would remain completely blank.
This may be acceptable for certain windows (like CLI windows, or EMACS which
has a REDISPLAY menu item), but is inappropriate for most other
applications.  For this reason, the default action is NOT to modify the
refresh status of SMART_REFRESH windows.  At the user's discretion, however,
wIconify WILL change a SMART_REFRESH window to a SIMPLE_REFRESH window when
it is iconified.  To request this, hold down the left ALT key when you
left-right click to iconify the window.  If the window was SMART_REFRESH, it
will first be brought to the font (so that its damage region is refreshed
and cleared) and then is changed to a SIMPLE_REFRESH window with
NOCAREREFRESH set, and finally it is iconified.  When the icon is openned,
the window will be changed back to SMART_REFRESH, and the window's border
and gadgets will be redrawn, but it is up to you to request that the program
restore the data displayed in the window.


The main functions of wIconify are all incorporated in this version of
wIconify.  The remaining additions are mainly the ability to customize
certain aspects of wIcoinfy (e.g, the NewCLI command performed, the menu
command key equivalents, the ability to prevent wIconify from openning a
window on specific screens, etc.) and in the programmer's interface to
wIconify (allowing programs to give their own icon images, and to respond to
clicking and openning icons in other ways).  These are being added, and
should be present in the next update.

wIconify is reasonably well behaved, and every effort has been made to
prevent it from locking up or crashing the machine.  There are numerous
places where wIconify can fail, however, and crashes may occur.  Please let
me know if any particular program crashes regularly, or in a repeatable way.

The program is getting larger than I had intended, but then it also does quite
a bit more than it used to.  Also, when the loader is separated from the
handler, it should reduce the program by at least 10K.  Then again, there is
still the programmer's interface code to add.